The 3rd Generation Partnership Project (3GPP) is a collaboration between groups of telecommunications associations and encompasses Radio, Core Network and Service architecture. 3GPP defines the Service Capability Exposure Function (SCEF) in the reference 3GPP TS 23.682 “Architecture enhancements to facilitate communications with packet data networks and applications”. FIG. 1 is copied from this reference and shows the architecture of the SCEF 102.
The Service Capability Exposure Function (SCEF) 102 provides a means to securely expose the services and capabilities provided by 3GPP network interfaces. The SCEF 102 provides a means for the discovery of the exposed service capabilities. The SCEF 102 provides access to network capabilities through homogenous network application programming interfaces (e.g. Network API) defined by Open Mobile Alliance (OMA), Group Speciale Mobile Association (GSMA), and possibly other signaling station bodies. The SCEF 102 abstracts the services from the underlying 3GPP network interfaces and protocols. Individual instances of SCEF 102 may vary depending on what service capabilities are exposed and what Application Protocol Interface (API) features are supported. The SCEF 102 is always within the trust domain. An application can belong to the trust domain or may lie outside the trust domain.
The Reference S2-151426, “Solution Update for Background Data Transfer, Huawei, HiSilicon, NTT Docomo, Apr. 13-17, 2015” describes 3GPP's solution for allowing an Application Server/Service Capability Server (AS/SCS) to schedule a background data transfer with the network. The approach described in this reference allows the AS/SCS to schedule a data transfer with the Policy and Charging Rules Function (PCRF) 104. The PCRF 104 is able to tell the AS/SCS when to start the data transfer. The following description of FIG. 2 is adapted from reference S2-151426.
In this approach, any of the available PCRF 104 in the network serving this geographic area can make the decision about a transfer policy for background data transfer for non-roaming User Equipment (UE).
In this approach the UEs targeted for background data transfer could be served by a single PCRF 104 or could be spread across multiple PCRFs serving the same or different geographic areas.
The transfer policy is finally stored in the Subscription Profile Repository (SPR) 204 together with a transaction reference granting approval of the request. This ensures that the transfer policy is available to every PCRF responsible for a UE which is subject to this background data transfer in the future. In addition, other (or the same) PCRF can take this transfer policy into account during subsequent decisions about transfer policies for background data related to other AS.
When the AS 202 contacts the PCRF 104 for an individual UE (via the existing Rx interface) at a later point in time the AS 202 needs to also provide the reference. The reference enables the Policy and Charging Rules Function (PCRF) 104 to correlate the AS 202 request (that is related to the UE) with the transfer policy retrieved from the SPR 204 (that is related to the AS). The PCRF 104 finally triggers Policy and Charging Control (PCC) procedures according to 3GPP TS 23.203 to provide the respective policing and charging information to the Policy and Charging Enforcement Function (PCEF) 206.
The AS 202 will typically contact the PCRF 104 for the individual UEs to request sponsored connectivity for the background data transfer.
In step 1 of FIG. 2, a 3rd party AS 202 may send a request for background data transfer for a set of UEs to the SCEF 102. The background data transfer request message contains application information, traffic information (e.g. the volume of data to be transferred per UE and the expected number of UEs), the desired time window and optionally, geographic area information. The Application Server (AS) does not provide any information about the identity of the UEs.
In step 2 of FIG. 2, the SCEF 102 authorizes the AS request. The SCEF 102 notifies the AS 202 at this point if the authorization fails.
In step 3 of FIG. 2, the SCEF 102 selects any of the available PCRFs and sends the background data transfer request to the PCRF 104 including the parameters provided by the AS. If the AS 202 provided geographic area information, the SCEF 102 transfers the geographic area to a corresponding network area (e.g. list of cell ids, TAs/RAs). A new interface is introduced for the interaction between SCEF 102 and PCRF 104 for the information exchange between AS 202 and PCRF 104 as this request is not specific to a given UE's IP-CAN session.
In step 4 of FIG. 2, the PCRF 104 queries the SPR 204 for all existing transfer policies (which may be equivalent to the request in step 3).
In step 5 of FIG. 2, the PCRF 104 determines, based on information provided by the AS 202 and other information (e.g. network policy, congestion level (if available), load status estimation of the required time window and network area, existing transfer policies) one or more recommended time windows for the AS data transfer. For each time window, the PCRF 104 optionally assigns a maximum aggregated bitrate for the set of UEs and a charging rate that will be applicable in the respective time window for the traffic that stays below the maximum aggregated bitrate. The maximum aggregated bitrate provided from PCRF 104 to SCEF 102/AS 202 is not enforced in the network.
In step 6 of FIG. 2, the PCRF 104 responds to the SCEF 102 with a reference ID identifying the approved grant and a transfer policy offer including one or more recommended time windows for the data transfer and optionally for each time window the maximum aggregated bitrate for the set of UEs and a charging rate.
In step 7 of FIG. 2, the SCEF 102 forwards the reference ID and the transfer policy offer to the 3rd party AS. The AS stores the reference ID for the future interaction with the PCRF 104.
In steps 8-11 of FIG. 2, if the transfer policy offer contains more than one time window, the 3rd party AS shall select one of the time windows and send another request for background data transfer message to inform the SCEF 102 and PCRF 104 about it.
If there is only one time window in the transfer policy offer, the AS 202 is not required to confirm.
In step 12 of FIG. 2, the PCRF 104 stores the reference ID and the new transfer policy in the SPR 204.
In step 4 of FIG. 2, when the AS 202 contacts the PCRF 104 at a later point in time for an individual UE (via the existing Rx interface), the AS 202 provides the reference ID. The PCRF 104 correlates the AS request with the transfer policy retrieved from the SPR 204 via the reference ID. The PCRF 104 finally triggers PCC procedures according to 3GPP TS 23.203 to provide the respective policing and charging information to the PCEF 206 for the background data transfer of this UE. The AS 202 will typically contact the PCRF 104 for the individual UEs to request sponsored connectivity for the background data transfer.
Reference S2-151237 (“Predicable UE Communication Pattern, Ericsson, NEC, Apr. 13-17, 2015) describes 3GPP's most recent solution for allowing an AS/SCS to schedule periodic communication with the network. The approach described in this reference allows the AS/SCS to schedule periodic data transfer with the network and provide the network with its expected mobility pattern. The PCRF 104 is able to tell the AS/SCS when to begin the data transfer. The following description of FIG. 3 is adapted from reference S2-151237.
The solution of FIG. 3 provides “Support of 3rd party interaction on information for predictable communication patterns”. The solution described here defines a mechanism to provide relevant information of a communication pattern of a UE or a group of UE to the corresponding core network node in order to enable network resource optimizations for such UE(s).
The SCEF 102 may receive communication patterns for the data traffic and/or the mobility pattern. Examples what kind of parameters may be contained in these communication patterns (CPs) are shown in the tables below. The SCEF 102 shall be able to select Communication Pattern (CP) parameters for the core network nodes from those communication patterns.
A set of CP parameters can be standardized, but all CP parameters are optional.
TABLE 1(Table 6.5.1.1-1 from S2-151237): Data traffic communicationpattern parameter examplesCommunicationpatternparameterDescription1) PeriodicTRUE: The UE communicates periodically/False:communicationNo periodic communication, only onindicatordemand. [optional]2) CommunicationDuration interval time of periodic communicationduration timer[optional, may be used together with 1)]Example: 5 minutes3) Periodic timeInterval Time of periodic communication [optional,may be used together with 1)]Example: every hour4) ScheduledTime zone and Day of the week when the UE iscommunication timeavailable for communication [optional]Example: Time: 13:00-20:00, Day: Monday5) Average dataAverage data volume per communication [optional]volume perExample: 2500 KBcommunication
TABLE 2(Table 6.5.1.1-2 from S2-151237): Mobility communicationpattern parameter examplesCommunicationpatternparameterDescription1) StationaryTRUE: The UE is stationary/False: The UE is mobileindication[optional]2) StationaryUE location information for Stationary [optional forlocationitem 1 is TRUE]Example: cell-id (or location information which is ableto be mapped to the cell-id in the network)3) Mobility areaArea information where the UE moves around[optional for item 1 is False] If it is not specified,the UE mobility is not restricted..Example: list of cell-ids or TA-list (or locationinformation which is able to be mapped to the cell-listsor Tracking Area (TA) list in the network)4) AverageAverage mobility speed for UE [optional for item 1 ismobility speedFalse]Example: speed in km/h (or just low/middle/highspeed)
The following assumptions are made for this solution:                SCEF 102 filters and forwards CP parameters based on the received communication pattern from the 3rd party service provider.        SCEF 102 provides the CP parameters to Home Subscriber Server (HSS) 302 which provides them to the selected appropriate functional entities (e.g. MME 304).        Only one set of CP parameters are valid at a time, i.e. if the same SCS/AS 202 or a separate SCS/AS 202 provides new CP parameters, then those override any CP parameters previously provided.        
SCEF 102 provides the selected CP parameters to the HSS 302 for distribution to the MME 304 based on the communication patterns of individual UEs or groups of UEs received from the 3rd party service provider. The signaling including CP parameters from SCEF 102 and HSS 302 is per subscriber level (as also HSS 302 to MME 304).
FIG. 3 (FIG. 6.5.1.3-1 from S2-151237) shows the signaling sequence for provisioning of CP parameters.
The 3rd party service provider notifies the SCEF 102 about the communication pattern for the UE or group of UEs. The SCEF 102 may query the HSS 302 for additional information, authenticates & authorizes the request and then selects the CP parameters based on operator policy or configuration. The SCEF 102 provides the CP parameters to the relevant node (e.g. MME 304 via HSS 302) that initiates the network resource optimization. The interface between SCEF 102 and AS/SCS is outside the scope of 3GPP and the messages in FIG. 3 are exemplary.
The contents of this section discussing UE requested bearer resource modification is adapted from section 5.4.5 of reference 3GPP TS 23.401 (“General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”).
The UE requested bearer resource modification procedure for an E-UTRAN is depicted in FIG. 4. The procedure allows the UE to request for a modification of bearer resources (e.g. allocation or release of resources) for one traffic flow aggregate with a specific QoS demand. Alternatively, the procedure allows the UE to request the modification of the packet filters used for an active traffic flow aggregate, without changing QoS. If accepted by the network, the request invokes either the Dedicated Bearer Activation Procedure, the Bearer Modification Procedure or a dedicated bearer is deactivated using the Packet Data Networks (PDN) Gateway (GW) Initiated Bearer Deactivation Procedure. The procedure is used by the UE when the UE already has a PDN connection with the PDN GW 404. A UE can send a subsequent Request Bearer Resource Modification Message before the previous procedure is completed.
In this procedure the UE signals a Traffic Aggregate Description (TAD) which is a partial Traffic Flow Template (TFT), together with a Procedure Transaction Identifier (PTI), and an EPS Bearer Identity (when the TAD operation is modify, delete or add to an existing packet filter). When the TAD operation is modify or delete, the packet filter identifiers of the TAD are the same as the TFT packet filter identifiers of the referenced Evolved Packet System (EPS) Bearer (as the concatenation of the TFT packet filter identifier and the EPS Bearer identifier represents a unique packet filter identifier within the PDN connection), for which resources are being modified. The TAD is released by the UE after it has received a TFT related to the current PTI from the network.
Steps 1, 2, and 5 of FIG. 4 are common for architecture variants with GPRS Tunnelling Protocol (GTP)-based S5/S8 and Proxy Mobile IPv6 (PMIP)-based S5/S8. The procedure steps marked (A) differ in the case that PMIP-based S5/S8 is employed and is defined in TS 23.402.
In step 1 of FIG. 4, the UE 402 sends a Request Bearer Resource Modification [Linked Bearer Id (LBI), Procedure Transaction Identifier (PTI), EPS Bearer Identity, Quality of Service (QoS), Traffic Aggregate Description (TAD), Protocol Configuration Options] message to the MME 304. If the UE 402 was in ECM-IDLE mode (where ECM stands for EPS Connection Management), this Non Access Stratum (NAS) message is preceded by the Service Request procedure.
The TAD indicates one requested operation (add, modify, or delete packet filters). If traffic flows are added, the TAD includes the packet filter(s) (consisting of the packet filter information including packet filter precedence, but without a packet filter identifier) to be added. The UE 402 also sends the QoS Class Identifier (QCI) requested and Guaranteed Bit Rate (GBR), if applicable, for the added traffic flows. If the UE 402 wants to link the new packet filter to an existing packet filter to enable the usage of existing bearer resources for the new packet filter, the UE 402 provides an existing packet filter identifier together with the new packet filter. If the UE 402 wants to change the GBR in addition, the UE 402 includes the GBR requirement of the EPS Bearer. The TAD is released when the procedure is completed.
When requesting for a modification of GBR (i.e. decrease or increase), the TAD shall include packet filter identifier(s) for which the GBR change request applies to. The UE 402 includes the GBR requirement of the EPS Bearer. The TAD is released when the procedure is completed.
When requesting a modification of a packet filter (e.g. change of port number), the TAD shall include packet filter identifier for which the change request applies to together with the changed packet filter information.
If the UE 402 requests for deletion of traffic flows, the TAD includes the packet filter identifier(s) to be deleted. If the packet filters to be deleted were mapped to a GBR Bearer, the UE 402 includes the new GBR requirement of the EPS Bearer.
The UE 402 sends the Linked Bearer Id (LBI) only when the requested operation is add, to indicate to which PDN connection the additional bearer resource is linked to. The EPS Bearer Identity is only sent when the requested operation is modify or delete. The Procedure Transaction Id is dynamically allocated by the UE 402 for this procedure. The UE 402 should ensure as far as possible that previously used PTI values are not immediately reused. The PTI is released when the procedure is completed. Protocol Configuration Options may be used to transfer application level parameters between the UE 402 and the PDN Gateway (GW) 404, and are sent transparently through the MME 304 and the Serving GW 406.
In step 2 of FIG. 4, the MME 304 sends the Bearer Resource Command [International Mobile Subscriber Identity (IMSI), LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol Configuration Options] message to the selected Serving GW 406. The MME 304 validates the request using the Linked Bearer Id. The same Serving GW address is used by the MME 304 as for the EPS Bearer identified by the Linked Bearer Id received in the Request Bearer Resource Modification message.
In step 3 of FIG. 4, the Serving GW 406 sends the Bearer Resource Command (IMSI, LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol Configuration Options) message to the PDN GW 404. The Serving GW sends the message to the same PDN GW 404 as for the EPS Bearer identified by the Linked Bearer Id.
In step 4 of FIG. 4, the PDN GW 404 may either apply a locally configured QoS policy, or it may interact with the PCRF 104 to trigger the appropriate PCC decision, which may take into account subscription information. This corresponds to the beginning of a PCEF-initiated IP-CAN Session Modification procedure as defined in TS 23.203, up to the point that the PDN GW 404 requests IP-CAN Bearer Signalling. When interacting with PCRF 104, the PDN GW 404 provides to the PCRF 104 the content of the TAD and, if applicable, the GBR change (increase or decrease) associated with the packet filter information contained in the TAD. The GBR change is either calculated from the current Bearer QoS and the requested Bearer QoS from the UE 402, or set to the requested GBR if the TAD indicates an add operation and no EPS Bearer Identity was received. If the TAD indicates an add operation, the requested QCI is also provided to the PCRF 104 unless an existing packet filter identifier is provided together with the new packet filter.
If the TAD operation is modify or delete, then the PDN GW 404 provides the Service Data Flow (SDF) filter identifier(s), previously assigned on Gx, that correspond to the received packet filter identifiers of the EPS bearer indicated by the received EPS bearer identity.
In step 5 of FIG. 4, if the request is accepted, either the Dedicated Bearer Activation Procedure (according to clause 5.4.1 of 3GPP TS 23.401 “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”), the PDN GW Initiated Bearer Deactivation Procedure (according to clause 5.4.4.1 of 3GPP TS 23.401) or one of the Dedicated Bearer Modification Procedures (according to clause 5.4.2.1 or 5.4.3 of 3GPP TS 23.401) is invoked. The PTI allocated by the UE 402 is used as a parameter in the invoked Dedicated Bearer Activation Procedure, the PDN GW Initiated Bearer Deactivation Procedure or the Dedicated Bearer Modification Procedure to correlate it to the UE Requested Bearer Resource Modification Procedure. This provides the UE 402 with the necessary linkage to what EPS Bearer to be used for the new traffic flow aggregate. The PDN GW 404 shall not modify the QoS parameters requested by the UE 402.
The PDN GW 404 inserts, modifies or removes packet filter(s) corresponding to the TAD into the TFT for the EPS bearer. When a new packet filter is inserted into a TFT, the PDN GW 404 assigns a new packet filter identifier which is unique within the TFT. The PDN GW 404 maintains the relation between the SDF filter identifier in the PCC rule received from the PCRF 104 and the packet filter identifier of the TFT of this EPS bearer. If all of the packet filter(s) for a dedicated EPS bearer have been removed from the TFT, the PDN GW performs the PDN GW Initiated Bearer Deactivation Procedure.
If the requested QoS is not granted (i.e. the requested QoS cannot be accepted or resources could not be allocated) the PDN GW 404 sends a Bearer Resource Failure Indication (with a cause indicating the reason why the request failed or was rejected) message, which shall be delivered to the UE 402.
In step 6 of FIG. 4, if the PDN GW 404 interacted with the PCRF 104 in step 4, the PDN GW 404 indicates to the PCRF 104 whether the PCC decision could be enforced or not. This corresponds to the completion of the PCEF-initiated IP-CAN session modification procedure as defined in TS 23.203, proceeding after the completion of IP-CAN bearer signalling.
In M2M communications the Service Layer (SL) aims to enable platforms for delivery of third-party value-added services and applications by supporting secure end-to-end data/control exchange between M2M devices and customer applications and to provide capabilities for remote provisioning & activation, authentication, encryption, connectivity setup, buffering, synchronization, aggregation and device management. SL provides interfaces to the underlying networks and enables capabilities using servers owned by Service Providers (SP) accessed through third-party content providers through Application Programming Interfaces (APIs).
An M2M/IoT service layer is specifically targeted towards providing value-added services for M2M/IoT type devices and applications. Standardization bodies such as ETSI M2M (“Machine-to-Machine communications (M2M) Functional Architecture”, Draft ETSI TS 102 690 1.1.1 (2011-10)) and oneM2M TS-0001 (oneM2M Functional Architecture) are developing M2M service layers specifically targeting sensor and device networks. Device Management (DM) is among the value-added services targeted by most SL platforms in order to provide solutions for issues such as firmware and software management, security and access control, device monitoring and logging, etc.
The oneM2M architecture is based on a Common Services Entity (CSE) which can be hosted on different types of network nodes (e.g. infrastructure node, middle node, application-specific node).
Within the oneM2M RESTful architecture (also known as Resource oriented Architecture or RoA) the CSE 502 supports the instantiation of a set of Common Service Functions (CSFs), as shown in FIG. 6. CSF functionality is implemented via resources which are uniquely addressable entities having a representation that can be manipulated via RESTful methods such as Create, Retrieve, Update, and Delete. These resources are addressable using Universal Resource Identifiers (URIs). A resource supports a set of attributes that store relevant information about the resource and may contain references to other resources termed child resources(s). A child resource is a resource that has a containment relationship with a parent resource and whose lifetime is limited by the parent's resource lifetime.
oneM2M is providing specifications using a Service oriented Architecture (SoA) approach (“Service Component Architecture” oneM2M-TS-0007, oneM2M Service Component Architecture-V-0.6.0) in addition to the RoA architecture introduced. The SoA architectural concept is based on considering as building blocks the functionality provided by distinct software modules and known as services. Services are provided to applications via the specified interfaces which are independent of vendor, product or technology. The SoA representation of a CSE 502 in oneM2M is shown in FIG. 7.
From a deployment perspective, FIG. 8 depicts configurations supported by the oneM2M architecture.
The following terminology is used in this context:                Application Service Node (ASN):                    An ASN contains one CSE 502 and contains at least one Application Entity (AE). As example, an ASN could reside in an M2M Device.                        Application Dedicated Node (ADN):                    An ADN contains at least one AE and does not contain a CSE 502. As example, an ADN could reside in a constrained M2M Device.                        Middle Node (MN):                    A MN contains one CSE 502 and contains zero or more AEs. As example, a MN could reside in an M2M Gateway.                        Infrastructure Node (IN):                    IN is a Node that contains one CSE 502 and contains zero or more AEs. There is exactly one IN in the Infrastructure Domain per oneM2M Service Provider. As example, an IN could reside in an M2M Service Infrastructure.                        Non-oneM2M Node (NoDN):                    A non-oneM2M Node is a Node that does not contain oneM2M Entities (neither AEs nor CSEs). Such Nodes represent devices attached to the oneM2M system for interworking purposes, including management.                        